This invention relates generally to computer systems, and more particularly to the access of input/output (I/O) devices in a non-pended bus design.
As it is known in the art, computer systems generally include at least one central processing unit (CPU), a main memory for storing data, at least one input/output (I/O) interface, and a system bus coupling the aforementioned devices to the CPU. The I/O interface generally has at least one port which is coupled to an I/O bus. The I/O bus provides access to one or more devices coupled to the I/O bus.
Generally, I/O interfaces are used to transfer data between the system bus and the I/O bus such that devices on the I/O bus are coupled to the remainder of the computer system. Many different types of devices may be resident on the I/O bus. For example, storage devices, devices which couple the I/O bus to other remote buses including other system buses within other computer systems, and other I/O buses, etc.
A basic problem encountered in computer systems is that I/O resources can, at times, be unavailable for a CPU to access because they are "busy". This problem can be aggravated in a multiprocessing system when a system bus has bandwidth greater than available I/O bandwidth.
One approach used to handle the problems associated with I/O resource unavailability is the use of a pended system bus. A pended system bus is a bus which allows multiple transactions to be outstanding, or in progress, at the same time. On a pended system bus, while one CPU is trying to access an I/O device which is currently busy, other CPU and bus initiators can continue to use the system bus. The system bus, therefore, is not stalled, as it is in the case of non-pended buses (discussed below), while waiting for I/O device access.
Unlike a pended bus, a non-pended bus allows only one transaction to be in progress at any given time. In the past, in order to solve the problems associated with I/O resource unavailability in non-pended bus designs, the I/O device stalls the requested transaction until it is able to satisfy the request. For example, the time it generally takes the I/O device to accomplish a task, such as a read from or a write to a memory, is many times greater than the clock cycle time of the CPU. Hence, the CPU waits on the system bus until the I/O device access is complete. This has a disadvantage in that it prohibits any other bus traffic from occurring while the stall is taking place. Further, the stall time could potentially be very long. Therefore, performance problems arise since the system bus cycle time is consumed while waiting for the I/O device access to complete.
One performance problem that may arise with stalling a non-pended bus while waiting for the I/O device access to complete, is the problem of "deadlock." A deadlock can occur when the CPU has control of the system bus and is stalled waiting for an I/O device access to complete while the I/O device has control of the I/O bus and is stalled waiting for the access to complete. When there is a deadlock neither transaction can proceed to completion, thereby hanging the buses indefinitely.
A deadlock can be discovered by timeout hardware which allows a certain maximum time limit for a transaction to complete before it will "time out." Upon discovery of a deadlock using this time limit, one solution to the deadlock situation is for the I/O device and the CPU to stop waiting on their respective buses and retry the transaction. Such a retry can be implemented in hardware and is one way to avoid the potential problems of stalling and deadlocks evident in a non-pended bus. An example of a retry signal implementation on a bus is described in U.S. Pat. No. 4,706,190. While suitable for use in a bus which directly supports a retry signal, such an arrangement requires that the signal bus protocol and hardware make provisions for assertion of the retry signal on the bus. This retry mechanism is not useful for those buses which are not specifically designed to support a retry signal.